The invention concerns a method and device for supporting a 6to4 tunneling protocol across a network address translation mechanism.
As described in the IETF documents RFC 1631, RFC 2663 and RFC 3022, Network Address Translation (‘NAT’) translates IPv4 addresses of a first address domain (‘Private IPv4 addresses’) into IPv4 addresses of a second address domain (‘Public IPv4 addresses’). The translation is carried out on the source addresses of outgoing packets and on destination addresses of incoming packets going through the NAT. Typically, the NAT is a function integrated in a router, connecting for example two IPv4 networks using different and incompatible IP addressing schemes.
There exist two basic types of NAT: either the process consists in substituting addresses with a one-to-one correspondence (i.e. each first domain address is associated with a unique second domain address) or in associating several first domain addresses with a single second domain address. The first NAT type is referred to as ‘N:N NAT’ and the second type as ‘X:Y NAT’, in the context of this document.
A problem linked to the use of X:Y NAT is that if the NAT's translation table solely consists of IP address mapping information it will not allow to uniquely identify the source host, since during the translation, X private addresses where translated into Y public addresses (with Y<X), which results in a loss of information. Consequently, the NAT has to use additional session information in order to be able to make the opposite translation, and to support a bidirectional communication. But, there aren't any fields in the IP header of a packet to unambiguously identify a session so a “multiplexing/de-multiplexing identifier” (abbreviated as “multiplexing identifier further in this document) needs to be defined for each protocol running over IP. Protocols such as TCP and UDP have the notion of ‘port’ which is used by NAT to create look-up tables to make the backward translation possible. For applications that run over other IP transport protocols or directly on IP, dedicated session information has to be identified for each protocol. Alternatives have been proposed to make those “portless protocols” transparently crossing NAT. For instance,
the document “Teredo: Tunneling IPv6 over UDP through NATs” by C. Huitema (Internet Draft of Sep. 17, 2002) describes an alternative method for providing services to IPv6 nodes located behind a NAT device. However, transporting IPv6 over UDP introduces an additional overhead and consequently has an influence on performance. Furthermore, additional specific servers have to be introduced into the network and the IPv6 hosts have to be upgraded.
Another alternative is described, in the document “Realm Specific IP: Framework” RFC 3102 of October 2001. However, as for the protocol described in the previous paragraph, additional servers are required and hosts need to be upgraded.
The document ‘Setup of 6to4 (NAT version)’ available from www.6to4.jp/settings/nat.html describes a NAT functionality in which the IPv4 address part of an 6to4 header of an IPv6 packet encapsulated in an IPv4 packet is updated with a public IPv4 address, resp. a private IPv4 address for outbound resp. inbound packets.